home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 23
/
Aminet 23 (1998)(GTI - Schatztruhe)[!][Feb 1998].iso
/
Aminet
/
misc
/
emu
/
IBMConv.lha
/
IBMConv
/
Doc1.21.doc
< prev
next >
Wrap
Text File
|
1997-11-17
|
21KB
|
469 lines
IBMConv Version 1.21 Documentation.
© 1992 D Trollope.
The legalities.
Permission is granted to distribute this archive provided that:
1. It is not distributed in part, the whole archive must be distributed.
2. It is not used in a commercial environment for commercial purposes.
(This could be arranged though...)
3. This notice is included in all copies.
4. Modified copies are marked below with the author name and modification
details, and I am notified.
5. All parts of the archive (code,documentation and executables) are
© 1992,1993 D Trollope, and although you are quite welcome to examine and make
use of it, don't distribute it as yours.
6. If you like the program why not make a donation to the author... This
archive is Public Domain though.
This version has not been modified by anybody but the original author -
D Trollope
No liability is accepted for the contents of the archive containing this and
other files relating to IBMConv. Use these files at your own risk.
The following should be included in this archive.
Documentation.DOC The documentation file.
IBMConv.h C Header file included by IBMConv.c
IBMConv.c C Source code for the executable provided.
(Lattice C V5.1)
IBMConv CLI executable program.
Contents.DOC A cutting of this section of documentation.
(You obviously have this!)
IBMFile.DOC A Dummy text file in IBM format for you to
experiment on.
AmigaFile.DOC A Dummy text file in Amiga format for you to
experiment on.
If something is missing, ask your source why!
The documentation.
This is a simple program which will read a text file and convert it to either
IBM/ST format, or AMIGA/UNIX format. To the non techies, this means that extra
control codes will be added/removed where appropriate when transferring text
files.
Note, this program will NOT read IBM/ST compatible disks, use CrossDOS,
MessyDOS, or DOS2DOS for this.
Using IBMConv.
IBMConv has four CLI arguments, there are keywords available to identify
them, but they can be ignored. Three arguments must be specified with or without
the keywords. These are the FROM, TO, and TYPE arguments. The fourth is an
option to stop any output being displayed (except errors). This option is called
QUIET:
IBMConv [FROM] Sourcefile [TO] Destinationfile [TYPE] Sourcefiletype [QUIET]
AmigaDOS file pathnames IBM or AMIGA No output
[NOXPND]
No destination
filename expansion
New to Version 1.21
Sourcefile and Destinationfile.
These are the files (with optional paths) a) to be read, and b) to be
written.
The destination does not have to specify a filename. You can give a directory
as the destination. You must supply an actual file (including its path) as the
source name.
IBMConv MS1:Text RAM: IBM
The above line will now work in this version, previous versions would have
failed.
Keywords can now be specified like this:
IBMConv FROM MS1:Text TO RAM: TYPE IBM
You can now just supply a destination directory without a file. You may
however supply the '/' of the directory. This is not needed though.
The sourcefile name can be used in the destination directory.
WARNING.
If you supply a destination file which already exists, or a directory
containing a file with the same name as the original file, a warning is given,
but the file is overwritten. No confirmation is given.
Sourcefiletype
This must be either "IBM" or "AMIGA" and is now case insensitive, ie.
"Amiga", "amiga", "AmIgA" will all be recognised as "AMIGA". Previous versions
were limited to upper case. All keywords are case insensitive.
The QUIET option prevents any output from being displayed during convertion.
The only exception to this is if an error occurs.
The NOXPND option prevents the program expanding the destination file. What
this means is, if a directory or device was supplied, the filename was added to
it. Eg.
IBMConv FROM RAM:Test.txt TO T: TYPE AMIGA
The destination therefore became 'T:Test.txt'. However, some devices didn't
like this, NIL: for example doesn't allow filenames. If you specified a filename
AmigaDOS asked for the volume NIL:
Using the NoXpnd option forces the program to use the destination file as it
is supplied. NIL: can therefore be used. While using NIL: seems pointless, it
can be used for seeing how long a file is in bytes (after convertion) and lines.
I also can find it useful for debugging when I don't want to save the output.
The third and final reason for this option, is that I do not know if any devices
will be produced in the future with the restriction of no filenames. If one is
produced, the program will be (in theory) compatible with it. I believe a little
forward thinking never hurt anyone did it?
The only point I will make with this option is if you supply a directory like
'T:' and used the NoXpnd option, you will receive a DOS error 210, but what do
you expect?
IBMConv FROM RAM:Test.txt TO NIL: TYPE AMIGA NOXPND
The above line works.
Examples.
To convert an Amiga text file (called Test.txt found in the RAM disk) to IBM
format ready for transfer to an IBM disk try the following:
IBMConv FROM RAM:Test.txt TO T:TestIBM.txt TYPE AMIGA
or
IBMConv RAM:Test.txt T:TestIBM.txt AMIGA
This reads "Convert the AMIGA text file RAM:Test.txt to IBM format and place
it in the file T:TestIBM.txt".
To do the opposite, convert an IBM text file (called Test.txt found in the
RAM disk) that has already been transferred to the Amiga to an Amiga
formatted disk, try the following:
IBMConv FROM RAM:Test.txt TO T:TestAmiga.txt TYPE IBM
or
IBMConv RAM:Test.txt T:TestAmiga.txt IBM
Supply just a destination directory such as:
IBMConv FROM RAM:Test.txt TO T: TYPE AMIGA } All Do
or
IBMConv RAM:Test.txt T: AMIGA }
or
IBMConv FROM RAM:Test.txt TO RAM:T/ AMIGA } The Same
or
IBMConv RAM:Test.txt RAM:T/ AMIGA }
or
IBMConv FROM RAM:Test.txt TO RAM:T AMIGA } Operation
or
IBMConv RAM:Test.txt RAM:T AMIGA }
You can use some, but do not need all the keywords such as:
IBMConv FROM RAM:Test.txt T: TYPE AMIGA
It makes no difference. You can in fact supply keywords, in a different
order, like this:
IBMConv TO T: FROM RAM:Test.txt TYPE AMIGA
Missing the TO keyword is also allowed, as long as the FROM keyword exists.
The following will work!
IBMConv T: FROM RAM:Test.txt TYPE AMIGA
However, missing the TO and FROM keywords will not work in this case:
IBMConv T: RAM:Test.txt TYPE AMIGA ; will not be allowed.
To stop any output being displayed
(with the exceptions of warnings and errors):
IBMConv RAM:Test.txt T: AMIGA QUIET
I hope you understand its use, if not, experiment on the two dummy text files
supplied. Convert the documentation too if you want, but make sure you use
backups!
To examine the files, I recommend using the HEX option in the AmigaDOS
command TYPE because using TYPE on its own shows no difference between the files
in a normal shell. When looking at the HEX values, look for the occurence (or
disappearance depending on the direction of transfer) of values 0D followed by
0A.
Errors.
Number Message
101 Minimum number of parameters is 3.
The are 4 (7 with keywords) possible parameters, 3 of which are
always needed. This means at least 3 should be specified.
102 Maximum number of parameters is 7.
The are 4 (7 with keywords) possible parameters, 7 of which is the
maximum when all the parameters have been used. This means at least
1 has been specified more than once, or extra irrelevant parameters
have been specified in the command line.
106 No file type has been supplied in the command line.
You haven't specified "IBM" or "AMIGA" in the command line.
107 1 file type please, more than 1 has been found in the command line.
The keyword "IBM" or "AMIGA" has been found in the command line more
than once. The "TYPE" keyword may have been used once, and not in
another occurence.
108 File type must be "IBM" or "AMIGA" (case insensitive).
The "TYPE" keyword has been specified but the word following is not
either of the keywords "IBM" or "AMIGA".
111 No destination file has been supplied in the command line.
The program cannot find a destination file. If you have supplied one
there may be a problem with other command line parameters, or a
space has been missed. Try placing the "FROM" keyword in front of
your file name (or path). This may not make it work, but will help
show the command line error.
112 Only 1 destination file please, more than 1 has been found in the
command line.
More than one destination file has been found. If you have supplied
one there may be a problem with other command line parameters, or a
space has been missed. Try placing the "FROM" keyword in front of
your file name (or path). Also use the "TO" keyword, and place '"'s
around the filenames (not the keywords, just the name. This may not
make it work, but will help show the command line error.
113 No destination lock has been possible.
An AmigaDOS Lock has not been possible on the destination file/
directory, and the program is not sure if the directory exists, or
if it is a file name that has been supplied.
116 No source file has been supplied in the command line.
The program cannot find a source file. If you have supplied one
there may be a problem with other command line parameters, or a
space has been missed. Try placing the "FROM" keyword in front of
your file name (or path). This may not make it work, but will help
show the command line error.
117 Only 1 source file please, more than 1 has been found in the command
line.
More than one source file has been found. If you have supplied one
there may be a problem with other command line parameters, or a
space has been missed. Try placing the "FROM" keyword in front of
your file name (or path). Also use the "TO" keyword, and place '"'s
around the filenames (not the keywords, just the name. This may not
make it work, but will help show the command line error.
255 Internal Error - MAXUSER_ERR.
This should never occur, but if it does contact me immediately, a
problem with the actual execution has arisen. Try re-executing the
command. If the problem persists, try playing around with the
command line parameters. A really persistant problem should be
attempted after a reboot then if all has failed contact me.
Please note, these are not DOS error numbers, as you will see they have no
meaning regarding AmigaDOS.
Warnings.
Number Message
101 Binary codes have been found in source file.
If extra binary codes are found in the file, a warning is given to the user.
This does not include tabs, they are not counted as binary codes. Extra symbols
such as '©' or 'ª' are also not counted as binary.
This warning may appear if the either the file actually has extra binary
codes, or if the file is not of the type specified. EG. If you supply an AMIGA
file specifying as an IBM file, the warning will appear. This is because the
program will be expecting different sequence of binary codes in certain places.
102 Warning, Bad end of line sequence found.
New to version 1.21.
This warning will appear in conjuction with the binary code warning. It is
displayed when a 0x0d code is found and it is not followed by a 0x0a, or vice
versa in IBM source files. When 0x0d is found in an Amiga source file this
message is also displayed.
103 Warning, Destination file being overwritten.
Previously known as warning 102.
If you supply a destination file which already exists, or a directory
containing a file with the same name as the original file, a warning is given,
but the file is overwritten. No confirmation is given.
104 Warning, Quiet option selected more than once.
Previously known as warning 103.
The QUIET option has been registered, but found more than once in the command
line. The program will continue as if only one QUIET option existed.
105 Warning, NoXpnd option selected more than once.
New to version 1.21.
The NoXpnd option has been registered, but found more than once in the
command line. The program will continue as if only one NoXpnd option existed.
I do have a few hints on use...
I use the program in conjunction with MessyDOS. Assuming you have a
MessyDOS device MS1: setup you can directly read from an IBM disk using
IBMConv:
IBMConv MS1:AUTOEXEC.BAT RAM: IBM
IBMConv uses the MessyDOS device to access the source file directly, and
write the converted file to the RAM disk. You could just as easily have changed
directory to MS1:, then typed:
IBMConv AUTOEXEC.BAT RAM: IBM
Make sure the IBMConv program is directly available to the shell though!
For all you people who download stuff from NPDSA via an IBM, here is a method
of transferring the UU-Encoded file to the Amiga, converting it to an Amiga
format file, AND decoding it to the decoded archive at once!
Lets assume you wish to download the file PROGRAM.UUE from the IBM disk you
hold in your hand using MessyDOS.
From a shell, CD to the directory you want the decoded file to appear and
type:
run IBMConv MS1:PROGRAM.UUE PIPE:TRANSFER IBM
UUDecode PIPE:TRANSFER
Using the above method reduces the need to convert the file to the Amiga,
saving it, converting it to Amiga format and then decoding it to another disk.
You just read the file directly, and write the decoded file directly. Easy huh?
The commands RUN, IBMConv, and UUDecode should be immediately available to
the shell, I usually place them in RAM:, and make RUN resident.
PIPE: and MS1: should be mounted also.
Compiling IBMConv.
IBMConv can be compiled by 'LC -L IBMConv.c'.
This version has been developed using Lattice C V5.1.
Versions 1.0, and 1.1 were developed on version 4.0. I do not believe it to
be V4.0 compatible because the INCLUDE files I originally developed it with were
slightly different, but I could be wrong on this. Let me know if you know
different.
Bugs in IBMConv, Past and Present.
Version 1.2
Version 1.2 was released with a major bug, 0x0d followed by 0x0a would not
get converted when 0x0d was the last character in the buffer and 0x0a being the
first of the next buffer. In the previous release I said 'I am confident that
this release is bug free, but they could be my fatel last words!', It was my
fatel (well almost) last words, it had not been totally fixed.
Version 1.21
This is the current release.
I cannot say that I am aware of any bugs at the moment, but as I have said
before, and have found out the hard way, has anybody ever written a bug free
program? However, the bug which I thought I had fixed at the last moment in
version 1.2 reoccurred, this is now fixed, I am absolutely positive of this
(I think!).
Previous versions gave the binary warning when it (correctly) found a
control Z, this code is often found at the end of MSDOS files and is now
suppressed. The warning will still occur if it is found elsewhere in the file.
The code is not copied to the destination if it is the last character in the
source.
All resources are now freed if the program is interupted by CTRL C etc. I
did not class this as a bug previously, just a drawback with using C, but now
its fixed, I found out how to call the deallocation routine when the program
exits, even if it's caused by a break etc.
Please, Let me know if you find any bugs, providing as much information as
possible. My address is given below.
Future.
There are a number of things I intend to do, and they are listed below.
Use even better dynamic memory allocation methods.
Allow a specified amount of memory to be used.
Tidy up the ParseCLIArgs function.
Add an option to output the prompt etc. to a window defined by the program.
Provide a decent front end.
Include a confirmation for overwriting destination files, and appropriate
command line option to force overwriting.
If you have any ideas please forward them to me.
History.
Version 1.0
This was extremely slow, and the IBM/AMIGA option operated differently,
it said the file type being written, but I felt that to indicate the source
file type made more sense so V1.1 came about. Besides, only I have version 1.0!
Version 1.1
A buffer system was added using 2K, in theory speeding up the program, and
it did, about 50% faster... I don't claim it to be fast though!!
IBM/AMIGA option changed, see above, it now indicates the source file type.
A progress report is now given, a full stop appears for every 2K read.
If an error occurs during opening a file, a new error message outputting the
DOS error number has been added.
Version 1.2
Previous code was not overly accurate when referencing LONG variables, not
set to 0L, just 0, and displayed using %d rather than %ld. Sorry, This is now
corrected.
A new buffer system has been employed for source AND destination files, work
being carried out in the buffers. The reason behind this is I expected it to be
faster than the system in 1.1. Now an 8K buffer is allocated for the source
file, and depending on the direction of transfer, a destination buffer of
8K/10K is allocated, and worked upon. This new system is between 9 to 10 times
faster than version 1.1. It is quite fast. An example of this is that a file
of approx 45K took approximately 1 minute 35 seconds (95 seconds), this version
takes approximately 5 seconds!
The IBM/AMIGA switch is now case insensative, ie. "Amiga", "amiga", "AmIgA",
will all be recognised as "AMIGA". Previous versions were limited to upper
case.
A new progress report has been employed displaying the number of bytes read
and written.
An additional feature showing the number of lines processed has been added.
I thought it might come in useful.
The 'QUIET' option has been added.
A warning is now displayed if extra binary codes are found in the file being
converted.
Version 1.21
Apart from the bug fix which is explained in the 'Bugs' section,
very little has been done to the program.
The code has been changed to be closer to the C standard
conventions (variables using lower case etc.).
Two functions have been used in place of the inline code in the
function main. These functions convert one buffer to the second.
This was carried out because it makes it easier to see what is
happening in the function main. The code has been optimised in
places to try to keep it fast but readable. I could probably make
it faster, but less understandable!
The 'NOXPND' option has been added.
Two new warnings have been added too. Warning 102 now becomes
`Warning, Bad end of line sequence found.'. Old warnings 102, 103
now become 103,104 respectively. 105 refers to multiple use of the
NOXPND option.
All resources are now freed if the program is interrupted by
CTRL-C etc.
My main priority with this release was to get the bug fixed,
because it did cause problems with large files.
The program also now uses WARN and ERROR return codes. If a
warning occurs, WARN is returned, no matter which warning it was.
Any error causes ERROR to be returned. FAIL is not supported,
because it is very difficult with this program to decide where to
draw the line between ERROR and FAIL.
Contact.
If you want to get hold of me, try the following address. and there
is no reason for it to change in the near future. It will probably
be correct for many years to come, but as with any of part of this
archive, there is no guarantee!
65 Ascham Road EMail dave.trollope@lucent.com
Grange Park
Swindon
SN5 6BE
England